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Abstract 

We describe the data acquisition system for the MuLan muon lifetime experiment 
at Paul Scherrer Institute. The system was designed to record muon decays at rates 
up to 1 MHz and acquire data at rates up to 60 MB/sec. The system employed 
a parallel network of dual-processor machines and repeating acquisition cycles of 
deadtime-free time segments in order to reach the design goals. The system incor- 
porated a versatile scheme for control and diagnostics and a custom web interface 
for monitoring experimental conditions. 

Key words: muon lifetime, high-speed data acquisition, high-speed electronics 



1 Introduction 



The MuLan experiment was designed to measure the positive muon lifetime 
to a precision of one part-per-million (ppm), a twenty-fold improvement over 
earlier experiments. The muon lifetime determines the Fermi constant Gp, 
which governs the strength of all weak interaction processes. In combination 
with other quantities, a precision determination of allows for precision 
testing of the standard model. 

The MuLan experiment was located in the 7rE3 beamline at Paul Scherrer 
Institute. It used a custom-built electrostatic kicker [1] to produce an in- 
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tense, low-energy, pulsed muon beam with beam-on periods of typically 5 /is 
and beam-off periods of typically 22 fis. During the beam-on (or accumula- 
tion) periods, the incoming muons were accumulated in a stopping target, and 
during the beam-off (or measurement) periods, the outgoing decay positrons 
were observed in a scintillator array. By recording the times of the outgoing 
positrons during the measurement period the /z + decay curve was constructed 
and the muon lifetime r M + was extracted. 

Reaching a precision of one part-per-million in r M + requires both enormous 
statistics (exceeding 10 12 decays) and careful control and comprehensive mon- 
itoring of systematic effects. To date, we have published results from our first 
measurement of the muon lifetime, with a precision of 11 ppm [2]. The anal- 
ysis of data collected in two production runs, each with 10 12 recorded muon 
decays, is currently underway. 

In this paper we describe the design, operation and performance of the data 
acquisition system that was developed for the MuLan experiment. In section 2, 
we briefly describe the experimental design and measuring devices. In section 
3, we discuss the design and layout of the data acquisition system, give details 
of our methods for control synchronization and data readout, and discuss 
the system performance. Finally, we discuss the custom system developed for 
online control and run monitoring in section 4. 



2 MuLan setup 

A schematic view of the MuLan setup is shown in Fig. 1. The setup comprised 
a target assembly for accumulating muons, a high-rate wire chamber for beam 
monitoring, and a fast-timing, finely-segmented, large-acceptance scintillator 
array for recording decay positrons. The stopping targets were mounted in- 
side the beam pipe vacuum and were rotated into the beam for production 
running and out of the beam for beam studies. The high-rate wire chamber 
(denoted the beam monitor) - with one horizontal and one vertical wire plane 
- was located downstream of the target assembly and immediately following 
the beam-pipe exit window. The scintillator array (denoted the MuLan ball) 
consisted of 170 triangular plastic scintillator tile pairs that were arranged in 
the form of a truncated icosahedron (i.e. a soccer ball geometry). 

The 2x170 scintillator tiles were each read out via a light pipe and a photo- 
multiplier tube to a VME-based, 500 MHz, 8 bit waveform digitizer. When an 
input signal exceeded a programmable threshold the waveform digitizer wrote 
both a time stamp and a consecutive sequence of flash ADC samples to the 
onboard FIFO memory of the corresponding digitizer channel (Fig. 2 shows 
a typical digitized pulse). The wire chamber was read out via pre-amplifiers 
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and discriminators to a custom-built FPGA that derived the x-y coordinates 
and hit times of the wire-plane coincidences. All chamber coincidences dur- 
ing the measurement period, and pre-scaled chamber coincidences during the 
accumulation period, were written into a VME-based memory unit (Struck 
SIS3600). Additional systems were responsible for the control and the moni- 
toring of the electrostatic kicker, beamline magnets, high-voltage system and 
other variables relating to experimental conditions. 



3 High speed data acquisition 

3. 1 Design 

The data acquisition in MuLan had to confront a number of challenges. First, 
to accumulate 10 12 decays implies both very high data rates (up to 50 MB/sec) 
and very large data volumes (up to 100 TB) must be handled with small dead- 
times, with any necessary deadtimes being scheduled to avoid distorting the 
positron time spectrum. Second, comprehensive monitoring of experimental 
variables and straightforward configuration for diagnostic measurements must 
be accommodated. 

In MuLan the acquisition does not read out decay positrons one-by-one. 
Rather, to handle the high data rates and avoid any deadtime-related distor- 
tions, we collected data in repeating acquisition cycles of deadtime-free time 
segments PI The approach utilized the VME-based memories in the waveform 
digitizers to temporarily cache the incoming data. Each acquisition cycle thus 
yielded a complete, distortion-free record of all over-threshold pulse shapes 
from the scintillator tiles over the entire duration of the measurement period. 
In normal operation the duration of one time segment was 5000 fill cycles or 
approximately 135 milliseconds. Between each time segment a short deadtime 
of roughly 2-4 ms was employed to complete the transactions that manage the 
acquisition. 

To handle high rates and facilitate diagnostic studies, the data acquisition 
was designed with a modular, distributed philosophy and implemented on a 
parallel, layered processor array. A frontend layer of seven dual-processors 
was used for the parallel readout of the waveform digitizers and the beam 
monitor. A slow control layer was used for the control and monitoring of other 
instrumentation such as high-voltage supplies and beamline components. A 



Under normal running conditions the waveform digitizer electronics was gated on 
during the measurement period and gated off during the accumulation period (see 
Sec. 3.4 for details). 
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backend layer was responsible for the assembly of the event fragments and 
the storage of the reconstructed events[f] Lastly, an online analysis layer was 
responsible for monitoring and diagnostics that ensured the integrity of the 
recorded data. 

3.2 Layout 

The data acquisition system is depicted schematically in Fig. 3. It shows the 
frontend layer responsible for waveform digitizer readout and beam monitor 
readout, the slow control layer responsible for control and monitoring, the 
backend layer responsible for event assembly and data storage, and the on- 
line analysis layer responsible for basic histogramming and integrity checks. 
The hardware platform comprised a networked cluster of Intel Xeon 2.6 GHz 
processors (with 1-4 gigabytes of memory) running Fedora Core 3 Linux. The 
acquisition software was developed using the MIDAS data acquisition [3] and 
ROOT data analysis [4] frameworks. To eliminate packet collisions that would 
degrade network traffic flow, we used two private gigabit ethernet networks. 
The first network handled traffic between the frontend layer and the backend 
layer, while the second handled traffic between the backend layer and the slow 
control and online analysis layers. This network segmentation significantly 
boosted performance and reduced the deadtimes between the frontend and 
backend layers. 

A key component of the acquisition system was the so-called "magic box" 
frontend (mbfe) process. This process was responsible for synchronizing the 
software defined data acquisition cycles (i.e. time segments) and the hardware 
beam on/off cycles (i.e. fill periods). To coordinate the software components, 
the mbfe process used remote procedure calls (rpcs) for network communica- 
tion between data acquisition modules on different processors. To coordinate 
the hardware components, the mbfe operated an FPGA-based programmable 
pulser that issued command signals to the beam kicker, waveform digitizers 
and beam monitor. In this manner all deadtimes were executed between the 
midas events rather than during the MIDAS events. The mbfe process exe- 
cuted on a dedicated single-processor frontend machine. 

The primary source of high-rate data were the 340 channels of waveform dig- 
itizers that record pulses from the 340 scintillator tiles of the MuLan ball. 
The digitizers were distributed over six vme crates and read out by six wave- 
form digitizer frontend (wfdfe) processes that executed on six dual-processor 
frontend machines. The data were transferred from the FIFO memories of the 

2 Herein we use the term "event" to indicate the software assemblies of recorded 
data that correspond to one time segment or one acquisition cycle. Typically one 
event will contain many tile pulses and many decay positrons. 
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waveform digitizer to the random access memory of the frontend processors 
via Struck SIS3100/1100 bridges [5]. Each bridge consisted of a SIS3100 vme 
card that provided access to each crate's vme bus, a SIS 11 00 PCI card that 
provided access to each processor's PCI bus, and a gigabit fiber-optic link 
connecting the two interface cards. 

A further source of high-rate data was the beam monitor wire chamber, which 
was generally activated for beam studies and de-activated for production run- 
ning. The beam monitor data was read out by the beam monitor frontend 
(bmfe) process that executed on an additional dual-processor frontend ma- 
chine. The beam monitor data was transferred from a Struck SIS3600 vme 
memory unit to the frontend processor random access memory via an addi- 
tional Struck SIS3100/1100 bridge. The read out of beam monitor data was 
performed continuously during each time segment by an asynchronous read- 
out loop, thus preventing any possibility of memory overflow in the SIS3600 
memory unit. 

The various processes for control and monitoring were executed on two slow 
control processors and provided the read out of information such as beamline 
magnet currents, photomultiplier voltages/currents, vme power supply volt- 
ages/currents, environmental magnetic fields and environmental temperatures. 
A beamline frontend (blfe) process and separator frontend (sepfe) process 
were responsible for the control and the read out of the beamline elements. 
A high voltage frontend (hvfe) process was responsible for the control and 
the read out of a LeCroy 1440 multichannel high voltage system powering the 
scintillator tiles. Additionally, a VME-crate frontend (psfe) process enabled 
monitoring of the vme power supplies and a 1-wire interface frontend (owfe) 
process enabled monitoring of various temperature sensors and magnetic field 
probes. Lastly, a scaler frontend (scfe) process provided the control and read 
out for the CAMAC scalers that record the primary proton current and beam 
monitor hits. 

Note that the slow control processes read out data in so-called "periodic" 
mode, i.e. at fixed time intervals that were asynchronous with the data acqui- 
sition cycle. Every slow control process wrote one copy of its data as a MIDAS 
databank to be stored in the main data stream and another copy of its data as 
an ASCII data file that was used by the online monitoring system. Note that 
the ASCII text files were written irrespective of whether or not a MIDAS run 
was currently underway. 

The data fragments from the frontend processes were asynchronously trans- 
ferred to the backend layer across the frontend network. Initially, the data 
fragments from the six waveform digitizer processes and the beam monitor pro- 
cess were transferred to individual memory segments on the backend machine 
BE01, i.e. one memory segment per frontend process. The MIDAS event builder 
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(mevb) process then re-assembled the fragments from the various wfdfe and 
bmfe processes into complete events. The reconstructed events were then 
written by the event builder process to a final memory segment known as 
the system memory segment. Note that the slow control databanks from the 
various slow control processes were directly transferred to the system memory 
segment and thus bypassed event building. 

The backend layer used two servers and a three stage pipeline to permanently 
store two copies of the entire MuLan dataset. First, the data were transferred 
from the system memory segment on the backend processor BE01 to a tempo- 
rary disk file on a local redundant disk array. We used an array of ten 250 GB 
disks controlled by a PCI raid controller. The raid was configured as RAID 10 
(a nested disk array with striping and mirroring) in order to provide both fault 
tolerance and high i/o performance. Next, the data files on beOI were asyn- 
chronously migrated from disk to both an lt03 tape robot system, mounted 
on processor beOI, and a remote redundant disk array, mounted on processor 
be02. Finally, the data files on BE02 were asynchronously migrated to either 
a second lt03 tape robot system or the PSI central data archive. This multi- 
step approach was used to minimize any possible delays in data-taking due to 
latencies associated with the tape storage or the archive storage. In addition, 
the disk files on the BE02-redundant disk array were available for any offline 
analysis work. 

The online analysis layer was used for integrity checking and online histogram- 
ming. A dedicated dual-processor machine hosted the online analyzer processes 
responsible for the various diagnostic and monitoring tasks, on the backend 
processor beOI. The online analyzer received events "as available" in order 
to avoid introducing any delays into the read out and the data storage. This 
layer is described in detail in Sec. 4. 



3.3 Frontend synchronization 

This section gives detailed information on the synchronization of the different 
components of the data acquisition. A diagram summarizing the various syn- 
chronization signals that were transmitted between the magic box frontend 
and the waveform digitizer frontends is given in Fig. 4. 

To initiate a new time segment the mbfe process sends a "start-of-segment" 
message to the magic box programmable pulser via a parallel port connection. 
This triggers transmission of a pre-programmed number of "run" gates to the 
waveform digitizers, thus causing each digitizer channel to store the pulses that 
were present during these gates. Each run gate corresponds to one 22 /is mea- 
surement period and was synchronized to the beam on-off transitions which 
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were also controlled by the magic box. 

After completing a run gate sequence the magic box pulser set an "end-of- 
segment" bit. This bit was identified by the mbfe process via a polling routine 
and then broadcast to the waveform digitizer frontend processes via a remote 
procedure call. Each rpc generated a program interrupt that causes the digi- 
tizer processes to read (i) the fill count register for each digitizer module, (ii) 
the data count register for each digitizer channel, and (iii) the FIFO memories 
of each digitizer channel I" 3 ! Each digitizer process separately reported the com- 
pletion of task (ii), denoted "done-data-count-read", and task (iii), denoted 
"done-FIFO-read", to the mbfe process via an rpc. Note that the read out 
of the digitizer FIFO memories could extend into the following time segment, 
but the requirement that all "done-data-count-read" messages were received 
before the start of that next segment ensured that the cached data in the 
digitizer FIFO memories were correctly assigned to their parent time segment. 

After the receipt of all "done-FIFO-read" RPCs from all digitizer processes, 
and the identification of the next end-of-segment bit in the magic box pulser, 
the mbfe initiates a new readout cycle via a new "end-of-segment" RPC to 
the digitizer processes. The "done-FIFO-read" requirement ensures the correct 
sequencing of the vme accesses for the various readout tasks. 

3.4 Digitizer readout 

The waveform digitizer frontend processes performed several tasks that in- 
cluded: the read out of the digitizer memories, the lossless compression of 
the digitizer data, and the assembly of the MIDAS databanks. The wfdfe 
processes ran on dual-processor frontend machines and used POSIX multi- 
threading functions to enable the simultaneous execution of multiple readout 
threads (one thread per segment). Mutexes were used for the thread-unsafe 
parts of the frontend code such as reading data from the digitizer memories 
and transferring data to the backend processor. The wfdfe threads also per- 
formed the lossless compression of digitizer data using the zlib libraryo An 
md5 checksum computation by the acquisition code before data compression 
and by the analysis code after data decompression was used to ensure the 

3 The fill count register stored the total number of run gates that were received by 
the digitizer. By reading and clearing this register between segments, it accumulated 
the number of fills for the previous segment. The data count register stored a pointer 
to the last entry in the FIFO memory of the digitizer channel. By reading this register 
between segments it was possible to determine the number of data words collected 
during the previous segment. 

4 zlib is a general purpose compression library that is based on a combination of 
the lz77 algorithm and Huffman coding [6]. 
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integrity of the compressed databank{3 

The waveform digitizer data were stored in MIDAS data banks with one MIDAS 
bank per digitizer channel. Within each bank the data were formatted as digi- 
tizer blocks with twenty four consecutive 8-bit ADC values, a 32-bit alignment 
block, a 16-bit fill stamp and a 16-bit time stamp. A header block stored the 
data count and fill count that were read from each digitizer - a redundancy 
enabling additional error checking. 

3. 5 Performance 

In the MuLan experiment, the data was stored on disk and tape in "runs", 
which comprised time-ordered sequences of software acquisition cycles of du- 
ration 135 ms, which were further subdivided into hardware-based fill cycles 
of duration 27 /is. A standard run was acquired over roughly 600 seconds, 
consumed about 10 GB of storage space, and contained 4 x 10 3 acquisition 
cycles or roughly 2 x 10 7 fill cycles. 

Under typical running conditions the average rate of recorded tile pulses was 
about 3 kHz per digitizer channel, 200 kHz per digitizer frontend, and 1 MHz 
in total. We stress these rates were time averages across the fill cycle, the 
instantaneous rates vary considerably over the fill period. The above pulse 
rates were equivalent to approximately 100 kB/s per digitizer channel, ap- 
proximately 6 MB/s per digitizer frontend, and approximately 36 MB/s in 
total. Herein we discuss the rate capabilities of the major components of the 
data acquisition - i.e. data read out, data compression, network transfer, event 
building and event storage - and the resulting performance of the complete 
system. 

Between time segments - i.e. between the magic box process identifying the 
end of the previous time segment and initiating the start of the following time 
segment - the waveform digitizer processes must read the data count registers 
of each digitizer channel and fill count registers of each digitizer module. The 
necessary enhanced parallel-port communications between the magic box pro- 
cess and the magic box pulser had typical delays of several microseconds. The 
necessary remote procedure calls between the magic box process and the wave- 
form digitizer processes had delays up to 100 microseconds. By comparison 
the sequence of about 60 data count reads (one read per digitizer channel) and 

5 We used the md5 cryptographic hash function to generate a checksum to im- 
munize the data stream against errors in compression, decompression, storage and 
transmission. The md5 function yielded an efficiently calculable 128 bit "finger- 
print" of the data. The md5 fingerprint was nearly certain to change if any errors 
were introduced into the data stream. 
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about 15 fill count reads (one read per digitizer module) across an entire vme 
crate took several milliseconds - thereby dominating the intervening dead- 
time between successive segments. Consequently, the data count and fill count 
reads imposed a data-rate independent 2-4 ms deadtime between successive 
time segments (a few percent deadtime for 135 ms time segments) . 

The data volume cached during the time segment determined the time required 
to read out and compress the digitizer data. Below a certain critical data 
rate the read out and compression were completed during the acquisition of 
the next segment, thereby adding no additional deadtime between acquisition 
cycles. Above this critical data rate the read out and compression were not 
completed during the acquisition of the next segment, thereby extending the 
intervening deadtime between acquisition cycles (for details see Sees. 3.3 and 
3.4). In practice, the critical data rate for minimal deadtime was found to be 
approximately 60 MB/s of uncompressed data or approximately 40 MB/s of 
compressed data. 

Following the read out and compression, the potential bottlenecks in data ac- 
quisition were the network transfer, event building and data storage. Event 
building involved copying data between memory segments and event storage 
involved copying data from memory segments to disk and tape. These tasks 
were limited by the rate capabilities of i/o operations, both to and from mem- 
ory, disk and tape. If event building was unable to keep pace, it blocked the 
data transfer from the frontend processes, thus potentially inhibiting the data 
acquisition. If data logging was unable to keep pace, it blocked the data trans- 
fer from the event builder, again potentially inhibiting the data acquisition. 
Under normal conditions of about 25 MB/s of compressed data the acqui- 
sition performance was not limited by network transfers, event building and 
data storage rates. However, for rates of 35 MB/sec and higher the system 
was unable to maintain the storage of two copies of the data-set. Note that 
data compression in the digitizer frontends - which reduced the data rates 
through event building and data storage by roughly 30% - was important 
in circumventing the rate limitations of network transfer, event building and 
data storage for high rate operation. 

In summary, our simple model for the rate performance of the data acquisition 
is (i) a fixed deadtime of several percent for raw data rates below 60 MB/s and 
(ii) a linearly increasing deadtime for greater data rates. The fixed deadtime 
was dominated by the read out of the data count and fill count registers 
between the time segments. The rate-dependent deadtime was dominated by 
the read out, lossless compression and databank assembly of the digitized 
pulses on the frontend processors. This interpretation was supported by results 
obtained from rate tests of the data acquisition setup shown in Figs. 5 and 
6. Fig. 5 shows a few percent deadtime below tile pulse rates of 2 MHz and 
a linearly increasing deadtime for tile pulse rates above 2 MHz. Fig. 6 shows 
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the increasing recorded pulse rate with increasing incident pulse rate for rates 
below 2 MHz and the saturation of the recorded pulse rate with increasing 
incident pulse rate for rates above 2 MHz. 

Note that the limit of 2 MHz (60 MB/s) was the rate capacity of the data read 
out and the lossless compression in the waveform digitizer frontend processes. 
To increase the capacity one could either increase the number of digitizer 
frontends, increase the speed of the frontend processors, or both. 



4 Online monitoring 

4-1 Online analyzer 

The online analyzer utilized the MIDAS analyzer package and a modular, mul- 
tistage approach to the analysis tasks. Specifically, the different analysis tasks 
were implemented as individual analyzer modules that could be added or re- 
moved from the analysis stream as required. Each analysis module had access 
to a global structure that contained both the raw data from the acquisition 
read out (e.g. raw data from the digitizer memories) and the derived data from 
the preceding modules (e.g. derived data such as fill numbers, time stamps, 
ADC arrays). Low-level modules were responsible for decompressing the raw 
data, decoding the digitizer data, checking the data integrity, and filling de- 
rived fields in the global structure. Histogramming modules were responsible 
for filling the histograms utilized by the low-level data monitoring that ensured 
the experimental setup was operating correctly. Such histograms included dis- 
tributions of fill numbers and hit times for the scintillator tile data and x-y 
profiles and time spectra for the beam monitor data. High-level modules were 
responsible for the "physics" analysis such as fitting of decay curves by detec- 
tor position and monitoring of gains and pedestals by scintillator tile. 

4-2 Run database 

A detailed record of the run-by-run evolution of all relevant quantities was 
crucial to ensuring the long term stability of the experimental set-up and 
maintaining a comprehensive record for systematic studies. Consequently, an 
important component of the MuLan data acquisition was the automated main- 
tenance of an electronic database of the running conditions. 

The midas data acquisition package included support for the MySQL open 
source database - the MIDAS logger process being responsible for the transfer of 
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parameters of interest from the MIDAS online database to the MySQL database 
at both the start of a run and the end of a run. The MySQL database con- 
tained run-by-run information derived from the MIDAS online database such 
as run start time, run stop time, the number of events, and hardware settings 
including the accumulation period and measurement period. The run-by-run 
comments that were entered by the shift operators - e.g. target material, 
magnet orientation - were also copied to the MySQL database by the MIDAS 
logger. 

In addition, a system was developed to enable the recording of such physical 
quantities as the gains, pedestals and fitted lifetimes in the scintillator tiles on 
a run-by-run basis. The system was based on a process that read the histogram 
files that were generated for the individual runs by the online analyzer, evalu- 
ated the interesting physical quantities such as gains, pedestals and lifetimes, 
and wrote the results into the MySQL database. 

The database provided a convenient approach to sorting data according to 
running conditions in subsequent analyses. For example, by using the infor- 
mation recorded in the MySQL database we automatically maintained summed 
histograms for different running configurations such as the target material and 
the magnetic field orientation. 



4-3 Web interface 

Another important component of the acquisition system was a custom web 
interface to the online analyzer histograms, slow control data and MySQL 
database. The interface provided a single, simple gateway to the online ana- 
lyzer, slow control and database information - irrespective of how the data was 
derived - that permitted both local control and monitoring and remote con- 
trol and monitoring of the experiment. It enabled the plotting of histograms 
both on a run-by-run basis and by experimental configurations such as the 
target material and the magnetic field. By using a modular structure the web 
interface was straightforward for users to modify or extend. 

The interface enabled plotting of online histograms and database information 
using a dynamic web page that utilized a set of ROOT macros and a PHP 
language interface between the ROOT macros and the HTTP server. The ROOT 
macros were responsible for generating the histograms and tables and creating 
the output in graphical and html formats. The PHP scripts were responsible 
for processing the user requests from the web interface, executing the corre- 
sponding ROOT macros with appropriate input parameters, and building the 
HTML-formatted output web pages. Various templates of ROOT macros were 
created to assist users in developing new macros that access the information 
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from the MySQL database, slow control system and analyzer histograms. Fig. 
7 shows a sample "trend" plot indicating the accumulation of muon decays 
during the 2007 production run. Fig. 8 shows a sample run-by-run histogram 
indicating the time distribution of tile hits during the fill cycle, i.e. both the 
accumulation period and the measurement period. 

The web interface also incorporated such items as the run plan and shift 
schedules and checklists. 



5 Summary 

We have described the data acquisition for the MuLan muon lifetime exper- 
iment. The acquisition recorded the digitized output from scintillator tiles of 
outgoing positrons from muon decay. The acquisition used the onboard vme 
memories in custom-built waveform digitizers, a repeating cycle of deadtime- 
free time segments, and a parallel network of dual-processor machines, to 
achieve our goals for integrity, performance and reliability. The system also 
featured a custom web interface for monitoring experimental conditions that 
enabled access to the online histograms, run database and slow control infor- 
mation. 

The system was capable of recording muon decays at rates up to approximately 
1 MHz and read out data at rates up to approximately 60 MB/sec with a few 
percent deadtime. The data acquisition system was used in MuLan production 
runs in 2006 and 2007 to record a total of 2 x 10 12 positive muon decays. 
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Fig. 1. Schematic view (not to scale) of the MuLan experimental setup showing a 
cross section view of the electrostatic kicker, vacuum pipe, target assembly, beam 
monitor and plastic scintillator array (MuLan ball). Note that the stopping targets 
were mounted inside the beam pipe vacuum, and were rotated into the beam for 
production running and out of the beam for beam studies. 
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Fig. 2. Sample pulse recorded by the 500 MHz, 8 bit waveform digitizers instru- 
menting the scintillator tile array. The horizontal axis is in clock ticks (ct) with 
~2 ns per tick. 
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Fig. 3. Schematic view of the acquisition layout. Shown are the frontend layer re- 
sponsible for the waveform digitizer and beam monitor read out, the backend layer 
responsible for event building and data storage, the slow control layer responsible 
for control and diagnostics, and the online analysis layer responsible for integrity 
checks and basic histogramming.. See Sec. 3.2 for the description of the individual 
components of the various layers. 




Fig. 4. Diagram of the synchronization of the fill cycles and the acquisition cycles 
across the different components of the data acquisition. The upper band represents 
the magic box pulser, the middle band represents the magic box frontend process, 
and the lower band represents a waveform digitizer frontend process. The horizontal 
traces indicate the control signals for fill periods and time segments that are gener- 
ated by the pulser. The open arrows represent the remote procedure calls between 
the frontend processes and the filled arrows represent the parallel port communi- 
cations with the pulser. The hashed regions indicate delays associated with either 
the hardware communications or the inter-process communications. For the wave- 
form digitizer process the sequence of data count read out, data read out, data 
compression, and databank transfer are also shown. 
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Fig. 5. The deadtime versus incident pulse rate for the full data acquisition setup in- 
cluding digitizer read out, lossless compression, event building and data storage. At 
pulse rates below 2 MHz the deadtime is several percent and dominated by the read 
out of the data count registers and the fill count registers in the waveform digitizers. 
At pulse rates above 2 MHz the deadtime is linearly increasing and dominated by 
the read out and the compression of the digitized pulses. 
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Fig. 6. The readout pulse rate and readout data rate versus incident pulse rate for the 
full data acquisition setup including digitizer read out, lossless compression, event 
building and data storage. The maximum throughput of digitized pulses (decays) is 
approximately 2 MHz (1 MHz) and is limited by the data read out and the lossless 
compression of the digitized pulses. 
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Fig. 7. Sample trend plot showing the accumulated statistics of muon decays for 
different setup configurations (target magnetic field left, target magnetic field right 
and all experimental configurations). The plot was automatically accumulated using 
the online analyzer histograms and the run database information. 
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Fig. 8. Sample run-by-run histogram showing the time distribution of tile hits during 
the fill cycle. The region to the left (right) of clock tick 2400 is the accumulation 
(measurement) period. The solid line is the least squares fit of the exponential 
decay curve in the measurement period. The plot was accumulated using the online 
analyzer and the fitting results are stored in the run database. For this particular 
run the run gate was extended into the accumulation period to record the decay 
positrons for the entire fill cycle. 
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